IBIS Macromodel Task Group Meeting date: 24 September 2024 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Altair: * Junesang Lee Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora System: * Dian Yang Raj Raghuram Cadence Design Systems: * Ambrish Varma * Jared James Dassault Systemes: Longfei Bai Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak [Kinger Cai] Chi-te Chen Liwei Zhao Alaeddin Aydiner Sai Zhou Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara Stephen Slater Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): * Walter Katz Graham Kus Micron Technology: Justin Butterfield Missouri S&T: * Chulsoon Hwang * Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Samsung: Jun-Bae Kim Siemens EDA (Mentor): * Arpad Muranyi Randy Wolff Signal Edge Solutions Benjamin Dannan Teraspeed Labs: [Bob Ross] Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: Yifan: Investigate with Arpad's SPICE circuit to see whether characteristics of rising and falling edges can help a model maker decide whether BIRD220.1 is applicable. - Done. Yifan said she had an update to present. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the September 17th meeting. Michael moved to approve the minutes. Dian seconded the motion. There were no objections. -------------- New Discussion: BIRD220.1 update: Yifan reported on her investigation using the SPICE driver model provided by Arpad. She performed simulations with the model driving 50 Ohms to V_fixture and swept V_fixture between Vcc and Vss. She had duplicated the results previously described by Arpad. For V_fixture values between Vcc and Vss, the edges of the rising and falling waveforms exhibited a plateau at V_fixture during the transition. The plateau corresponds to the period when neither transistor is active, as the transistor turning off is shut off before the other transistor is turned on, to minimize crowbar currents. Yifan had set up a similar experiment with simple inverter chain pre-drivers for the pullup and pulldown stages. The pullup pre-driver stage consisted of 9 inverters, while the pulldown stage consisted of only 7. Because of the throughput delay skew between the two pre-driver stages, the output waveform edges exhibited the same "plateau at V_fixture" effect. Yifan concluded that testing with a V_fixture of Vdd/2 and looking for the plateau behavior is a useful method for determining whether there is effectively a single pre-driver path. If the output edge(s) contain a plateau at V_fixture, it implies that there are two distinct pre-driver paths. If the plateaus are seen, then it is likely that BIRD220.1's algorithm cannot be applied to the device. Arpad asked whether the lack of a plateau was enough to indicate that BIRD220.1 could be applied. For example, if a device has two distinct pre-driver stages, but the delay difference is small, then plateaus would not be seen. Would BIRD220.1 work properly in that case? Yifan and Chulsoon said they believed that it would work in that case, but Yifan said she would investigate this question further. Ts4file and [Ramp]: Michael reviewed some new proposed language regarding Ts4file and Ramp, which was an extension of the language used in [External Model]. Michael asked whether it would help to introduce a new "bandwidth" keyword and drop the requirement for [Ramp]. We would no longer have to worry about crosschecking [Ramp] in that case. Arpad said he might be sympathetic to that idea, but he would have to discuss the ramifications with his development colleagues. Walter said we know what edge rate means, it's the edge rate expected from this device into a certain load. We already have [Ramp] to provide that, and we can say it's a "first-order estimate of driver switching characteristics" in the cases where we have newer or better modeling information available ([External Model], Ts4file). Michael observed that even if we add a new "bandwidth" keyword, it doesn't solve any of our problems if the data it contains is not consistent with other keywords. Arpad asked whether Michael was suggesting the new keyword should provide data in the same ballpark as Ts4file with a given stimulus, or I-V and V-t tables, etc. If the keyword is just there to help tools make initial set-up decisions or crosstalk simulation decisions, does it have to be strictly checked against the other keywords? Michael said a naive model maker might be creating a Ts4file model for AMI, but they get warnings about [Ramp] not matching I-V tables. So, they might just twiddle their [Ramp] values to make the warnings go away. Walter said he would complain to the model maker in this case for producing a bad model. He said that a user or tool can sanity check the [Ramp] data. If someone gives you a model with a [Ramp] dt of 1ps when it should really be about 100ps, then shame on the model maker. Arpad said he would take the [Ramp] value with a grain of salt in that case and use the new keyword (e.g., Ts4file) to come up with a better first-order estimate. Michael asked whether consensus was that we don't need a new keyword, and [Ramp] should be consistent with I-V and with newer keywords. Arpad said he didn't think that was the consensus. He thought the benefit of a new keyword was that a model maker could use it to provide bandwidth information, and then they wouldn't have to include [Ramp] and worry about the confusing crosschecks. Walter said there are two philosophies on the parser. One is that it is just a syntax check and not responsible for quality of the data. The second is that even if it does quality checking it can't catch everything. Sometimes garbage- in garbage-out. Walter noted that we don't currently check [Ramp] dt vs. the V-t waveforms. Why should we now worry about checking it vs. the Ts4file? He said if a model maker put a bad [Ramp] value in the model, the user could run a step-response simulation, see that it doesn't match the dt value, and complain to the model maker. Michael asked what the simulation consequences might be. Walter said you might get bad run-time performance of the simulation if the initial step size is wrong because of a bad dt value, or your crosstalk scan results may be invalid because you're saturating improperly. Arpad suggested that we might add new subparameters to [Ramp] to specify the loads matching the waveform loads. If we did that and added two sets of dt values for rising and two sets for falling, then we could have [Ramp] data for test cases analogous to the rising/falling waveforms. The parser could then test the [Ramp] dt against the rising/falling V-t tables. Michael asked whether adding this new information to [Ramp] would add any useful data about the buffer. He said the principal point was still the same in his mind. If the model provides extra data, it needs to be crosschecked against the other data in the model. Ambrish asked what the point of adding a new keyword would be. He asked why we couldn't just make [Ramp] serve the same purpose. Arpad and Michael said the issue with [Ramp] is that it's currently subject to some confusing cross- checking (and lack of cross-checking) by the parser. Ambrish suggested that we could go through the specification and clear up any confusion and fix the language. Arpad noted that cross-checking could still be complicated for the parser, for example vs. Ts4file, or even worse [External Model]. Michael said today [Ramp] is only partially cross checked (dV vs. I-V tables), and even that may happen in cases where it's likely irrelevant, for example when Ts4file is provided. The parser currently demands (checks) that [Ramp] is consistent with I-V data (if it is provided), but when Ts4file appears, and it is supposed to be used instead of the I-V data, then what should the parser check? Ambrish suggested that we should remove any requirement to cross-check [Ramp] data at all and state that it is only bandwidth information. Michael said that saying [Ramp] isn't required at all is one extreme. He said the other extreme is to say that if it's there it should be crosschecked against everything. Arpad said it's currently hard to determine when [Ramp] is a fundamental part of the model or just providing edge rate/bandwidth information. If we had a new keyword, then it could provide the bandwidth information. [Ramp] could then be made optional, with the understanding that if it's provided it will be cross- checked. Micheal asked whether we want simulation information (bandwidth initial estimate) included in the buffer model. - Michael: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. New ARs: Yifan: Further investigate the feasibility of using the plateau test to decide whether BIRD220.1 is applicable for a given device model. ------------- Next meeting: 01 October 2024 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives